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SYSTEM AND METHOD 



5 FIELD OF THE INVENTION 

The present daimed invention relates generally to the field of electronic 

procurement systems. More particularly, the present daimed invention relates 

U to a line item approval system for purchase requests in an electronic purchasing 

and procurement environment. 

, Si' ■ 

it? ■ 

!t» BACKGROUND ART 

•■4? ■ 

'^^ The Internet has become the dominant vehicle for data commimicatioris 

with a vast collection of computing resources, interconnected as a network from 

b- sites aroimd the world. And with the growth of Internet usage has come a 

yj- ■ 

S 15 corresponding growth in the xisage of Internet devices, wireless devices and 
services in a way different from tiie traditional uses of such devices. 

The growing base of Internet users has become accustomed to readily 
accessing Internet-based services, which traditionally were restricted or limited 
20 to the "dient/server" environment, at any time from any location. Accessibility 
to traditional business services and products over the Internet means enterprises 
have to adjust to new paradigms of transacting business. 

Consequently, some organizatioi« are, for example, implementing e- 
25 commerce and customer relationship management (CRM) strategies to increase 
revenue and bring them doser to their customer base. But organizations that are 
committed to an e-business strategy realize that their procurement operations are 
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an equally critical aspect of their business. By implementing a sound e- 
procurement solution, organizations can truly integrate with their supply chain 
partners and realize dramatic business efficiencies and cost savings in 
purchasing everything from office supplies to services and raw materials. 

5 

For any organization, procuring goods and services is a core business 
function that is critical to successful operations of the company. All 
organizations must procure "indirect" goods such as office supplies and other 

3 materials that support business operations and enable maintenance and repair 

Jv 10 operations (MROs) to function. 



In addition, many orgaruzations must also procure "direct" goods, such as 
raw materials or components that are used in manufacturing processes. Other 
goods or services that orgaruzations must procure include travel, consulting 
15 services and equipment. 

Many large organizations have dedicated resources that handle 
procurement at a corporate level By centralizing procurement, organizations 
can bring control over the entire process and improve their purchasing 
20 efficiencies. Unfortunately, in many organizations, procurement is still a 

fragmented, paper-intensive process that involves many forms, phone calls, and 
approval cycles. Just as procurement requires interfacing with multiple 
suppliers, it requires interacting with different areas of the organization (e.g., 
accoujnting, management, lines of biisiness, receiving, etc.) each of which may 
25 have different processes and approval flows. 
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As organizations begin to embrace e-business technologies for selling 
goods and serving their customers online, they are also beginning to look at the 
efficiencies that e-commerce technologies can bring their internal procurement 
operations. Thus, e-procurement is quickly assuming a highly strategic role 
5 within the e-business strategies of many organizations. 

With e-procurement, organizations can move the entire purchasing 
K- catalogs into a central catalog of products from approved suppliers, helping 
Q buyers quickly locate goods and services, E-procurement helps automate the 
'I'l 10 formerly time consuming review process typically required to approve 
jJi requisitions and initiate purchases. Finally e-procurement helps the organization 

realize efficiencies by accelerating the purchasing process, identifying existing 
ijj inventory to minimize redundant purchasing, detecting imauthorized spending, 

determining purchasing patterns for improved budgeting, and ensuring contract 
15 compliance. ^ 

As the number of business applications on the Internet increases, having 
restricted content and very limited information about goods and services 
transactions over the Internet impairs the ability of purchasing professionals to 
20 take advantage of Internet technologies and provide efficient and cost effective 
services. 

Some organizations have implemented on-line purchasing requisition 
systems that allow groups and individuals within a group to participate in the 
25 approval of purchase requisitions made to suppliers. Figure lA illustrates a 
prior art electronic purchasing environment. In the example shown in Figure 
1 A, a purchase request is typically approved by the approval group 150. In the 
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particular example, before a purchase order can be sent to a supplier, all the 
individuals e.g.. A- D identified in the purchase requisition as having approval 
authority must execute the purchase requisition before the requisition can be 
transformed into a purchase order. This type of approval process is typically 
referred to as the requisition level approval. 

In the purchasing environment shown in Figure 1 A, a refusal by one of 
the identified approvers (e.g., A - D) to approve a line item in the purchase 
requisition would lead to a total rejection of the purchase requisition (Figure IB). 
An individual approver may decline approval of a specific line item in a 
purchase requisition for a variety of reasons, among which may include the lack 
of authority to sign off on a dollar value of a line item, not having enough 
information on a particular line item, etc. In the requisition level approval 
depicted in Figures 1 A and IB, purchase requisition approval can be inefficient, 
limiting and time consuming and require multiple approval iterations before the 
requisition is converted into a purchase order. 
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SUMMARY OF INVENTION 

Accordingly, to take advantage of the myriad of e-commerce applications 
being developed, an e-purchasing system is needed that has extensibility 
capabilities to allow user requests from purchasing requisitioners to the e- 
purchasing system to be approved into a purchase order based on a line item 
based approval scheme. Further, a need exists for "out-of-the-box" solutions to 
allow technically ujisophisticated end-users to coimect to the Internet and 
perform sophisticated purchasing and procurement decisions and activities not 
available in the prior art in an organization's purchasing environment. A need 
further exists for an improved and less cosdy device independent system, which 
improves efficiency and provides electronic requisition services to various users 
of different configurations without losing the embedded features designed for 
these devices. 

What is described is aii e-purchasing system having a portal server 
supporting a robust purchasing and procurement system providing a wide range 
of features that purchasing and procurement applications require including 
storing capabilities for various purchasing and procurement functions in a 
business environment. In one embodiment of the present invention, the 
proctirement system includes a catalog management system that integrates 
information from multiple external catalogs into a consolidated catalog of goods 
and services from approved suppliers to enable a purchasing or procurement 
agent to purchase items over the Internet. 

In one embodiment of the present invention, the purchasing processing 
system includes a reqviisition and order management module that helps 
organizations streamline the requisitions process in the organization. The 
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reqtdsition and order management module allows users to request multiple 
items from different suppliers or a single requisition from a plurality of back-end 
resource servers on the Internet and transforms the content into a format suitable 
for delivery to the purchasing requisitioner. 

Embodiments of the present invention further include a line item 
approval system that allows multiple approvers to sign a purchase requisition by 
approving only line items associated with each approver in the process of 
generating a purchase order. The line item approving system allows the e- 
purchasing system of the present invention to automatically process purchasing 
requests regardless of whether all the lines of any itemized list of goods being 
requisitioned are individually approved by identified approvers of the 
requisition. 

More specifically, embodiments of the present invention bj^q directed to a 
system and a method for accepting in-bound order requests with a matrix of 
approvers with each approver authorized to approve the purchasing of one or 
more line itemized goods or services. The line item approval system of the 
present invention allows an approver to approve the purchase requisition by 
either approving items in the purchase requisition on a line-by-line basis or by a 
blanket approval at ttie requisition level. 

Having an approver approve the purchase requisition on a line-by-line 
basis allows the electronic purchasing system of the present invention to 
generate a purchase order based on a partially approved purchase requisition or 
to decline the purchase of items in the purchase requisition based on the same 
approval process. In general, embodiments of the present invention vary the 
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degree of approving supplier or buyer requests in a plurality of purchase orders 
or requisitions from a plurality of web-based order catalogs in the electronic 
proctirement envirorunent. 

Embodiments of the invention also include a process manager system that 
tracks all the approvals executed by the electronic ptirchasing system of the 
present invention. The process manager communicates with the line item 
approval system to track and notify approvers in the approval matrbc of the 
status of a purchase requisition submitted to the electronic purchasing system. 
The process manager further generates an approval graph of identified 
approvers for approving a particular requisition. The approval graph allows the 
identified approvers to check on the detailed approval information of each 
approver on the particular requisition. 

EmbodimentS'of the present invention include an electronic mailing 
system that helps to notify the identified approver of a particular requisition of 
the presence of the requisition in the approver's email in-box. From the in-box, 
the approver is able to automatically approve or decline the line items ihey are 
responsible for in the requisition. 

These and other objects and advantages of the present invention will no 
doubt become obvious to those of ordinary skill in the art after having read the 
following detailed description of the preferred embodiments which are 
illustrated in the various drawing figures. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



The accompanying drawings, which are incorporated in and form a part 
of this specification, illustrates embodiments of the invention and, together with 
the description, serve to explain the principles of the iiivention: 

5 

Figure 1 A is a block diagram of a prior art electroruc purchasing system; 

Figure IB is a block diagram of a prior art electronic purchasing system 
having a requisition level approval process; 

Figure 2 is a block diagram of one embodiment of the electronic 
purchasing system of the present invention having a line-by-line requisition 
approval process; 

Figure 3 is a block diagram of an embodiment of tj^e architecture of the 
electronic purchasing system of one embodiment of the present invention; 

Figxire 4 is a block diagram of an exemplary process flow implementation 
of a purchase requisition of an embodiment of the present invention; 

20 

Figure 5 is a block diagram of an exemplary pvirchasing environment of 
one embodiment of ihe present invention; 

Figure 6 is a block diagram of one embodiment of the purchasing 
25 processing system of the present invention; 



10 



Ul' 



15 
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Figure 7 is a block diagram of an embodiment of the process manager of 
Figure 6 of the present invention; 



Figure 8 is an exemplary screen display of one embodiment of the 
5 approver's graph of the present invention; 

Figure 9 is an exemplary screen display of one embodiment of the 
i approver's in-box of the present invention; and 



ISfLO Figure 10 is an exemplary block flow diagram of one embodiment of the 

purchase order generation process of the present invention. 



iiJis 



20 



25 
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DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Reference will now be made in detail to the preferred embodiments of the 
invention, examples of which are illustrated in the accompanying drawings. 
While the invention will be described in conjunction with the preferred 
5 embodiments, it will be imderstood that they are not intended to limit the 
invention to these embodiments. 



M On the contrary, the invention is intended to cover alternatives, 

(Kiss a 

■0. modifications and equivalents, which may be included within the spirit and 

%J 10 scope of the invention as defined by the appended Claims. Furthermore, in the 

i|r following detailed description of the present invention, numerous specific details 

' ~ s. 

' are set forth in order to provide a thorough understanding of the present 
Ql invention. However, it will be obvious to one of ordinary skill in the art that the 
i If present invention may be practiced without these specific details* In other 
;3: 15 instances, well-known methods, procedures, c^^mponents, and circuits have not 

been described in detail as not to unnecessarily obscure aspects of the present 

invention. 



The invention is directed to a system, an architecture, subsystem and 
20 method to manage purchase requisition approvals in a e-commerce 

proctirement and purchasing environment in a way superior to the prior art. In 
accordance with an aspect of the invention, an e-procurement and e-purchasing 
system provides users with a line item approval process of order requisitions 
electronically processed on the Internet. 

25 

Numerous specific details are not set forth in order to provide a thorough 
imderstanding of the present invention. However, it will be recognized by one 
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skilled in the art that the present invention may be practiced without these 
specific details or with equivalents thereof. 

Figure 2 depicts an e-commerce procurement and purchasing 
environment of one embodiment of the present invention. The on-line 
purchasing and procurement environment 200 shown in Figure 2 comprises 
computer server 210, e-purchase system 220, Interface 230, Database 240, 
Directory 250 and Memory 260 coupled a common commimication channel. 

Server 210 is coupled to provide an e-platform application server for the e- 
purchasing environment of the present invention. Server 210 provides a user 
with a single sign-on facility to the e-purchasing system 220 of the present 
invention, as well as the ability to customize the e-purchasing system 220. Server 
210 also provides scalability and high availability to the user. 

The e-purchasing system 220 is coupled to server 210 to provide an on- 
line centralized control for buying goods and services for enterprise operations. 
The e-purchasing system 220 further provides a business-to-business application 
for purchasing and procurement professionals within an orgaruzation in the 
enterprise. The e-purchasing system 220 is extensible to allow non-professional 
purchasing and procurement persons within the enterprise to purchase 
consumables such as office supplies, small office equipment and services from 
suppliers on the Internet. 

Still referring to Figure 2, Interface 230 couples to e-purchasing system 220 
to provide a foimdation for order submissions, and the communication between 
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a customer and legacy systems and the e-purchasing system 220 of the present 
invention. 

Interface 230 further supports secure transmission of data over public and 
5 private networks, as well as the storage of documents, tracking of services and 
the management of tasks. In one embodiment of the present invention. Interface 
230 supports the American National Standards Institute (ANSI) ASCII 12 and 
i^^ other communication interface standards. Interface 230 further supports the use 
CI of tools for mapping, translation and conversion of any file format such as 
v310 Electronic Data Interface (EDI) to a different file format. 

: 

'%J ■ 

/ Database 240 is coupled to the e-pur chasing system 220 to provide 

ordering and catalog information to the user. Database 240 may be an "off-the- 
I n shelf" software product such as an Oracle database software developed and sold 
;;i 15 by Oracle corporation of Redwood £ity, California. In the present invention, 
data is stored in database 240 in the form of data objects with associating data 
attributes. 

In the e-purchasing system 220 of the present invention, database 240 
20 provides an intermediary storage facility of catalog information where orders 
originated by a user are stored. In-boimd orders are processed by e-purchasing 
system 220 using order information retrieved from the catalogs stored in 
database 240. The e-purchasing system 220 transinits out-boimd order 
documents based on available catalog information from a supplier to the buyer. 

25 

Directory 250 ("LDAP") is coupled to the e-purchasing system 220 to 
store membership information of users of the e-purchasing system 220. 
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Directory 250 also stores information on the stxppliers, as well as location 
infornriation of buyers and sellers in order to facilitate an effective and efficient 
communication of order and supply information between enterprises. 



'*i 10 

Hi 



•SB!? 



Memory 260 is coupled to the server 210 to store transient copies of 
purchase requisitions stored in database 240. A purchase order requisition of 
catalog information stored in memory 260 has a one-to-one correlation with data 
objects stored in database 240. Information stored in memory 260 are stored as 
data objects or the like in a manner well known in the art. 



J1 Referring now to Figure 3, a block diagram of one embodiment of the e- 

purchasing system 220 of the present invention is shown. As shown in Figure 3, 
m e-purchasing system 220 comprises catalog managing module 300, catalog 

! . 

iji process manager module 310, line item approval processing (LIAP) module 320 
5| 15 and rule engine module 330. Also shown in Figure 3 is EBJ interface module 340 
which is coupled to LIAP 320. 

To make products available to buyers, suppliers organize product 
information into catalogs. The product information structure in a catalog is a 
20 hierarchy of categories with items under these categories. The ways of 
representing this information vary from supplier to supplier, even among 
suppliers of similar products. 



Catalog management module 300 allows suppliers to map their existing 
25 catalogs to the e-purchasing system 220 using a set of graphical interface tools. 
Catalog management module 300 allows for quick real-time catalog creation and 
maintenance by providing the creation of buyer managed content. 
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Catalog management module 300 further enables a system administrator 
of the e-purchasing system 220 to create and maintain a standardized structure 
that maps supplier catalog data to an e-procurement and purchasing 
environment. Catalog management module 300 also provides the system 
administrator with the envirorunent to create and manage catalogs of group- 
specific buyers and suppliers and generates requisitions and purchase products. 

Process manager module 310 is coupled to catalog management modxile 
300 and the line item approval module 320 to enable end-users to create web- 
%| 10 based applications that define the different tasks in the approval of purchase 
requisitions, specifying who should perform them and mapping out how the 
process flows from one approver to another. The process manager module 310 
includes a timer that processes an approver's approval of line items in a purchase 
requisition. 



Si 
, 

Si 

IS 



(i^s 15 



The process manager module 310 queries approvers identified in a 
purchase requisition to track the status of the approval process with respect to 
each purchase requisition processed by the e-purchasing system 220. The process 
manager module 310 further verifies that specified approval requirements and 
20 policies set forth in the e-purchasing system 220 have been met. 



LIAP 320 is coupled to catalog management module 300 to provide a 
framework for automatically processing line item approvals by identified 
approvers within, an organization for line items in a purchasing requisition. 
25 LIAP 320 provides supply requisitioners the flexibility of having requisitions 
totally or partially approved by a group of identified approvers in the electronic 
purchase process. LIAP 320 also provides users the ability to interactively track 
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the requisitions approving process by scanning a series of computer screens and 
i;^er in-boxes to identify those line items in a particular requisition that have 
been approved or declined. 

5 An approver of the present invention is any individual user who 

authorizes an existing requisition to become a purchase order. An approver can 
be one of a group of approvers, can be mandatory or optional approver, and can 
\^ delegate approval authority to another. A color coding scheme provided by the 
Q LIAP 320 also allows the approver to track those line items in a particular 
10 requisition that the approver approves or declines. 

■ 

,2 ' Still referring to Figure 3, rules module 330 is coupled to LIAP 320 to 

1^1 provide the underlying business rules that control the operating transaction 
; 5.^ principles of the e-purchasing system 320. In the present invention, rules module 

;y f 15 330 is configurable with generalized statements that allow system admiiustrators 
to control the flow and behavior of e-purchasing system 220. The underlying 
business rules semantics are not as complex as a full programming language and 
therefore allow the user to perform typical customizations such as page layouts, 
icon layouts and other "click and surf functions t3^ical in Internet computing 
20 without requiring any programming experience. 

Figure 4 is a block diagram depiction of an exemp^Iary data flow of the 
Open Buying on the Internet (OBI) standard which is the underlying standard 
utilized in Interface 230. The data flow shown in Figure ji illustrates the 
25 interaction of tiiese entities: requisition 410, Buying 420 and Supplier 430. 
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Requisition 410 represents the user with a need for a product or service, 
who meets this need by querying the supplier 430 catalogs for the required 
items. The requisition 410 generates order requests and querying order status to 
the e-purchase system 220 using an Internet browser. 

5 

Buyer 420 represents a purchasing management and information system 
which supports purchasing and procurement within an enterprise. These 
systems include an OBI server for receiving OBI order requests and retrieving 

''^f OBI orders. The system further processes requisition profile information, trade 

'A? 

% 10 partner information and other information necessary to complete an order. The 

ui 

buyer 420 also negotiates and maintains a contractual relationship with the 
^ supplier 430. 

5 , S 

ijl Supplier 430 maintains a dynamic electronic catalog that represents 

itj 15 accurafe product and price information that can be tailored based on the 

organization's affiliation of the requisitioner 410. Product and price information 
reflects the contract with a buyer. The supplier's catalog must be integrated 
effectively with the inventory and order management system and an OBI server 
for sending OBI order requests and receiving OBI orders. 

20 

Figure 5 is a block diagram illustration of an exemplary line item approval 
processing environment of one embodiment of the e-purchasing system 220 of 
the present invention. As shown in Figure 5, the line item approval processing 
environment comprises purchasing system 220, process manager 310, an 
25 exemplary approver matrix 510, an exemplary approval graph matrix 550 and 
database 240. 
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The LIAP 320 processes line item approvals of the present invention. The 
LI AP 320 handles the processing of purchase requisitions through a series of 
approval steps until the requisition is approved and becomes a purchase order. 
The LIAP 320 generates an approver matrix 510 that defines the list of approvers 
based on a multi-segment number accoimting codes that identify a business imit 
(e.g., division, department, project, etc.) to be billed for an order or specific line 
items on an order and commodity codes which identify a particular set of 
products or services. 

In one embodiment of the present invention, the LIAP 320 is implemented 
to provide both requisition level approval and line item level approval. In the 
present invention, an approver becomes part of the approval process depending 
on particular line items in the requisition. 

The line item approval process of the present invention provides a more 
defined way in which a user is added to the approval process. It also allows 
certain line items to be approved that may not depend on the approval of the 
other line items in a particular requisition. For example, in the prior art's 
requisition level approval process having a five line item requisition, an 
approver may not want to approve a requisition because of one line item out of 
the five. 

Therefore, this "all-or-nothing" scenario of the prior art disallowed the 
other line items in a particular purchase requisition to be approved. In the line 
item approval process of the LIAP 320 of the present invention, an approver may 
decline one line item but yet approve other line items in the requisition which 
allows the purchase order to be created for the approved line items. 
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Still referring to Figure 5, the LIAP 320 generates an approver matrix 510 
as part of an attribute of the LIAP 320 workflow process (Figure 6). The 
approver matrix 510 is implemented as an array of approver names and 
approval conditions. Each row of approver matrix 510 presents an entry for one 
5 approver. Each column of the approver matrix 510 presents a single condition, 
such as maximum approval amount. Other than the approver's name, conditions 
are based primarily on commodity codes and accounting codes. The approval 
process definitions use the approver matrix 510 to identify the appropriate 
approver or approvers for each purchase request. 

10 

'^i Additionally, the process manager 310 generates an approval graph 520. 

;^ The approval graph 520 provides a matrix of identified approvers for a particular 

requisition. The approval graph 520 contains information about the lines to 

H • 

Iff which each approver is added- In the approval graph matrix 520 shown in 

fll 15 Rgure 5, a user can view, on a computer screen, the detailed approval 

information for each of the boxes (e.g.. A- D) by clicking on any of the boxes. 

Detailed information on the approver appears on the user's computer 
screen in the form of a drop down window (Figure 9). Also, unlike the prior art 
20 approval chain, the approval graph 520 is not serially linked. Thus, once a user 
submits the requisition, the process manager module 310 may send an email to 
ttie first set (first in each of the parallel chains) of approvers with only relevant 
lines items requiring their approval. In other words, a particular approver only 
sees the line items that are relevant for him/her. 

25 

These approvers can approve or decline or partially approve the 
requisition. If there is at least one line item that is approved, the requisition is 
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transmitted further to the next approver until the purchase order is generated. If 
all the line items are declined by each of the identified approvers to the 
requisition, then the approval process ends and the purchasing system 220 will 
not generate a corresponding purchase order to that particular purchase 
requisition. 

Figure 6 is block diagram depiction of one embodiment of the LIAP 320 of 
the present invention. As shown in Figure 6, the LIAP 320 comprises workflow 
module 600, task in-box 610, approver matrix generation module 620, workflow 
case module 630, EJB interface module 640, commtmication interface module 650 
and purchase order generation module 660. 

The workflow module 600 handles the flow of the approval process of 
requisitions presented to the LIAP 320. The workflow module 600 coordinates 
the various approvals and denials that each identified approver to a line item in 
a particular requisition must resolve. The workflow module 600 also routes 
requisitions for approvals through the purchasing system 220. Furthermore, the 
workflow module 600 sets the rules to which each approver must adhere. 

Such rules may include the escalation of a line item approval by an 
identified approver to a superior who may not have originally been listed as one 
of the approvers of the reqviisition. Alternatively, the rules also provide for a 
delegation mechanism that enables an identified approver to delegate the 
approval process to a subordinate who may not have also been listed as one of 
the original approvers. 
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Escalation also provides a process of assigning an approval request to 
another individual in the event that the currently-assigned individual, as the 
primary approver, fails to act upon a request v/ithin a specified period of time- 
Hie workflow module 600 also coordinates the flow of the approval process from 
5 the LIAP 320 and the process manager 310. 

The workflow module 600 also provides the approver with the ability to 
H=V view approval request in the approver's in-box 610 when the approver logins 
CI into their computer system. Task in-box module 610 stores the in-box 

^^10 information associated with each approver in the approval process. In one 

31 

i,pj embodiment of the present invention, task in-box 610 populates the identified 
approver's in-box to generate a purchase order by accumulating the approved 

CI 

jTj line items in a particular purchase requisition in purchase order generation 

\U module 660. 

lii 15 ^ 

An approver matrix module 620 is included as an attribute of the 
workflow module 600. The approver matrix 620 is implemented as an array of 
approver names and approval conditions that the system administrator may 
setup. Each row of the approval matrix presents an entry for one approver. 

20 Each column presents a single condition, such as the maximum approval 
amoimt. Other than the approver's name, conditions based primarily on the 
commodity and accounting codes are used. Other approval conditions 
authorizing an approver to approve a particular line item can be added to the 1 
approval matrix 620 to further distinguish that particular approver from other? 

25 in a particular requisition. ' 
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The workflow case module 630 of Figxjre 6 is a unit within the workflow 
module 600. An approvable object has to be converted into a workflow case for 
the workflow module 600. The workflow case module 630 consists of one or 
more workflow tasks. The workflow task is a mit of work for each individual 
approver. The operations each approver can perform include approve, decline, 
reassign, delegate, etc. In addition to an approver, a workflow task is also 
associated with an approver. 

The LIAP 320 communicates with the process manager module 310 via 
interface module 640 such as an Enterprise Java™ Beans interface ( which is a 
proprietary interface of Sun Microsystems'^^0- EJB interface module 640 takes a 
requisition processing request submitted to £he LIAP 320 and queries the 
process manager module 310 on the status of requisitions, approvers, etc. Feed 
back information from the process manager module 310 is transmitted via the 
EJB interface module 640 to the LIAP 320 in response to requests to the process 
manager module 310. In order to achieve maximim\ scalability, it becomes 
necessary to provide an interface for the LIAP 320 to communicate with the 
process manager 310. The EJB interface module 640 is scalable and robust and 
provides a seamless integration of tiie process manager functionality into the 
LIAP 320. 

Communication interface .module 650 provides a communication channel 
between the purchasing system 220 and a commimication medium, such as 
email, to notify an identified approver the presence of an approval request. 



Figure 7 is a block diagram depiction of one embodiment of the internal 
architecture of the process manager 310 of the present invention. As shown in 
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Figure 7, the process manager 310 comprises EJB interface module 700, approval 
notification module 710, setup logic service module 720, approval graph 
generation module 730, workflow control module 740 and process item list 750. 

EJB interface module 700 is coupled to the process manager 310 to 
communicate with the LIAP 320. Interface 700 performs the same functions as 
Interface 640 (Figure 6). 

The purchase approval tracking in the process manager module 310 is 
handled by the setup service module 720 which is initiated when a purchase 
requisition is submitted to the LIAP 320. The setup service module includes a 
timer that times the approval of a request by an approver. In one embodiment of 
the present invention, a requisitions access to the approval process is timed to be 
approximately 50 seconds. 

Approval Graph generation module 730 generates the approval graph 
after a requisition has been submitted to the LIAP 320. The approval graph 
module 730 provides the services to modify the approval process from the buyer 
side. All modifications to the approval graph are communicated to the process 
manager module 310 by a system administrator of the e-purchasing system. 

Workflow through tihe process manager module 310 is controlled by 
workflow control module 740. The workflow control module 740 tracljs each line 

item approver corresponding to each requisition to determine when the 

I 

approver has acted on a given line item. As line items are approved or declined, 
the workflow control logic 740 tracks and notifies other approvers in the 
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approval chain via approval notification module 710 regarding the status of a 
pending requisition. 

Process item list 750 provides a list of active processes in the process 
5 manager module 310. A user of the e-purchasing system 220 may access the 
process item list 750 by accessing the process manager screen (Figure 8) . The 
user will see the requisitions that the user submitted from the LIAP 320. The 
:5 user may select the process and it will display a form with the name of the 
"tf approver that is currently assigned to the requisition details and the buttons for 
'J: 10 approving or declining- 

: 

If the user chooses to approve the requisition, the requisition is assigned 
m to a second approver and it will appear in the process item list 750. Once the 

lush 
i 

iJI user acts on the requisition as a second approver, the requisition will be removed 

■CI 

iti 15 from the process item list 750, as there will be no more approvals. However, if 
there is a line item decline, ihe requisition initially will be available to the user in 
the process item list 750 because it does not require any more approvals. 

Figure 8 is an exemplary screen display 800 of one embodiment of the user 
20 in-box 810 of the present invention. The approval monitor window 810 

illustrates all line item information that the approver will need to either approve 
or deny a requisition. 

As depicted in Figure 8, the user in-box 810 comprises a listing of the 

j 

25 requisition number, the owner of the requisition and tiie quantity and pricing 
information of the items being requisitioned. The approval in-box 810 also 
includes an approve selector 830 and an approve-all 835 selector to enable the 
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! 15 
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requisition approve to either partially approve line items in a particular 
requisition or all the lines items presented in the particular requisition. To 
approve the set of line items in the user in-box 810 (e.g., 
BOOKCASE.36X48,3SHLF;., DESK.DBL.PED.60X30 M, etc.) the approver 
partially approves each individual line item by clicking on the identified line 
item and check marking the selection and then clicks on the approve button 830 
to approve the particular selection. Alternatively, the user may click on the 
approve all 835 button to approve the items presented in the approver's in-box 



P 810. 

'■4 • 



Figure 9 is an exemplary screen display 900 of one embodiment of the 
process manager screen showing the approval graph of the present invention. 
The approval process monitor window 900 illustrates details of line item 
information for each approver. 



As depicted in Figure 9, the approval process monitor window 900 
comprises a matrix of all the approvers for a particular requisition. A user can 
click on one of boxes 910A - 910D to check on the details of each approver in the 
matrix. When a user clicks on the box with the corresponding name of the 
20 approver, a drop-down window 920 appears with the approval details of the 

approver. The detail information shown in drop-down window 920 may include 
the approver's full name, the type of approver (e.g., cost center approver), the 
line items that the approver has either approved or declined and the approver's 
authorized maximum dollar approval amoimt. 



Still referring to Figure 9, the user may click on different tab options in 
window to view additional information regarding a particular requisition. Once 
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the user has viewed and decided on the desired tab, the user may select the 
desired tabs by choosing from tabs 930. For example, clicking on the tab labeled 
"shipping" will give the user detailed shipping information about items listed in 
a purchasing requisition. 

Figure 10 is a data flow diagram of one embodiment of the line item 
approval system 320 of the present invention. As shown in Figure 10, identified 
line items of a specific purchase requisition 960 are selected after those line items 
O have been approved by the appropriate authorized approvers. The approved 
3 10 line items of the selected line items are then cumulatively presented to a 
purchase order generation module 970. 



i; 

m 



The purchase order generation module 970 subsequently generates a 
corresponding purchase order itemizing the line items approved during the 
15 approval process. In one embodiment of the present invention, those line items 
that are declined in the purchase requisition 960 may be cumulatively bundled in 
a dummy file that is accessible by the identified approvers for a corresponding 
purchase requisition. 

20 The foregoing descriptions of specific embodiments of the present 

invention have been presented for purposes of illustration and description. They 
are not intended to be exhaustive or to limit the invention to the precise forms 
disclosed, and obviously many modifications and variations are possible in light 
of the above teaching. The embodiments were chosen and described in order to 

25 best explain the principles of the invention and its practical application, to 

thereby enable others skilled in the art to best utilize the invention and various 
embodiments with various modifications are suited to the particular use 
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contemplated. It is intended that the scope of the invention be defined by the 
Claims appended hereto and their equivalents. 
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